<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<link rel="Stylesheet" type="text/css" href="doc.css" />
<title>Transaction Nesting</title>
</head>
<body>
<h1><a name="top">Transaction Nesting</a></h1>
<p>
Both read-only and read-write <em class="CodeName">Transaction</em>s can nest to any depth.
The most common examples of transaction nesting occur in the commit phase of the transaction
life-cycle:  <a href="triggers.html">trigger commands</a> are executed in nested
read/write transactions and pre- and <a href="listeners.html">post-commit</a> listeners are
called in nested read-only transactions.
</p><p>
Post-commit listeners are called only when a root transaction (on that is not nested in
some other transaction) commits.  This is necessary because even after a nested transaction
has committed, its changes can be rolled back if its parent (or some ancestor) rolls back.
Pre-commit listeners are invoked at every level of nesting, because a parent transaction
may assume the data integrity conditions guaranteed by triggers when it resumes following
the commit of a child transaction.
</p><p>
Validation is performed on all changes when a root transaction commits, because it must
include the changes performed by trigger commands in nested transactions.  Validation has
the last word in the committing of a transaction.
</p>

<h2>Inheritance of Transaction Options</h2>

<p>
The EMF Transaction API defines a number of standard <a href="options.html">options</a>
for read/write transactions.  Nested transactions inherit these options from their parents.
The standard options cannot be disinherited.  For example, if a parent transaction does
not send post-commit notifications, then none of its descendents will, either, even if
they explicitly specify <em class="CodeName">false</em> for that option.
</p><p>
Nested transactions can, however, add options (set them <em class="CodeName">true</em>)
that their parents do not have (or have them set <em class="CodeName">false</em>).
For example, a child transaction can disable notifications.  When its parent commits, the
changes that it reports will simply exclude any that occurred during the execution of the
child.
</p><p>
The inheritance of custom options in an <a href="extending.html">extension</a> of the
transaction API is defined by that extension.
</p>

<hr/>

<p>
<a href="https://www.eclipse.org/legal/epl-2.0/">Copyright (c) 2006, 2007 IBM Corporation and others.</a>
</p>
</body>
</html>
